Skip to content
This repository has been archived by the owner on Jun 26, 2023. It is now read-only.

chore: update pubsub interface, multiaddr and remove protons #89

Merged
merged 6 commits into from
Apr 12, 2021

Conversation

vasco-santos
Copy link
Member

@vasco-santos vasco-santos commented Apr 7, 2021

This PR adds some minor tweaks following up from feedback on #87 and updates multiaddr

Moreover, updating all the dependencies and removing protons in favour of protobufjs for smaller bundles and avoiding bundle problems with web-encoding

Most of the changes are auto generated files

Needs:

Unblocks:

@vasco-santos vasco-santos force-pushed the chore/update-pubsub-interface branch 2 times, most recently from 5204d56 to a372212 Compare April 7, 2021 15:52
@vasco-santos vasco-santos changed the title chore: update pubsub interface chore: update pubsub interface and remove protons Apr 7, 2021
* @returns {Uint8Array} message id as bytes
*/
getMsgId (msg) {
const signaturePolicy = this.globalSignaturePolicy
switch (signaturePolicy) {
case SignaturePolicy.StrictSign:
// @ts-ignore seqno is optional in protobuf definition but it will exist
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Protobuf definition in libp2p specs has this as optional, however it is basically an outdated thing...

receivedFrom: from,
data: message,
topicIDs: [topic]
}

// ensure that the message follows the signature policy
const outMsg = await this._buildMessage(msgObject)
msgObject = utils.normalizeInRpcMessage(outMsg)
// @ts-ignore different type as from is converted
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of the signatures, we have this "hack" where we also add the receivedFrom property and from is converted to a different type from the protobuf. Of couse ts does not like this, but I did not want to change this inner logic in this PR

@@ -62,7 +62,9 @@ module.exports = (common) => {
expect(psB.peers.size).to.equal(1)
expectSet(psB.topics.get(topic), [psA.peerId.toB58String()])
expect(changedPeerId.toB58String()).to.equal(first(psB.peers).id.toB58String())
expect(changedSubs).to.be.eql([{ topicID: topic, subscribe: true }])
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the type object we cannot check this deep eql anymore

@vasco-santos vasco-santos changed the title chore: update pubsub interface and remove protons chore: update pubsub interface, multiaddr and remove protons Apr 8, 2021
@@ -47,7 +54,7 @@
},
"homepage": "https://github.com/libp2p/js-interfaces#readme",
"dependencies": {
"@types/bl": "4.1.0",
"@types/bl": "^4.1.0",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably should be "^5.0.0" now, Alex updated it and it was released yesterday, bl@5 has been out for a week or so too thanks to Alex as well

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bl seems like a weird thing to use at the interface level, perhaps it's something we can pull out in future?

It's only used in one place and from the type def it looks like it's only necessary because the exported BufferList can't be treated as a Uint8Array based on the type heirachy.

@@ -396,7 +396,7 @@ class PubsubBaseProtocol extends EventEmitter {
if (msgs.length) {
// @ts-ignore RPC message is modified
msgs.forEach((message) => {
if (!(this.canRelayMessage || message.topicIDs.some((/** @type {string} */ topic) => this.subscriptions.has(topic)))) {
if (!(this.canRelayMessage || (message.topicIDs && message.topicIDs.some((topic) => this.subscriptions.has(topic))))) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oo, was this a bug that types picked up?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because the protobuf definition does not state topicIDs as required. As far as I know, all implementations send an empty arrau and not undefined and this has not been a problem. But could be as it is not spec'ed as required

}

/** Properties of a Message. */
interface IMessage {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are the properties here all both optional and allow null?

Copy link
Member Author

@vasco-santos vasco-santos Apr 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is generated from the protobuf spec for pubsub where no part of the message is required. But basically, "Optional fields may be undefined depending on the signature policy and message ID function."

Copy link

@rvagg rvagg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sgtm (didn't review the two generated files, I'm assuming there's not much to say there)

The only major thing that stands out is the liberal use of ? combined with |null in the types. I suppose if this is just an initial go at external facing interfaces then that might an ok start, but it seems to suggest some looseness that maybe could be tightened up later?

@rvagg rvagg mentioned this pull request Apr 10, 2021
77 tasks
@vasco-santos
Copy link
Member Author

The only major thing that stands out is the liberal use of ? combined with |null in the types. I suppose if this is just an initial go at external facing interfaces then that might an ok start, but it seems to suggest some looseness that maybe could be tightened up later?

As we reuse the same definition for several types of pubsub messages supported, the protobuf states them as optional, which makes them possibly null. More details in review comments

// topicCID = cid(merkledag_protobuf(topicDescriptor)); (not the topic.name)
message TopicDescriptor {
optional string name = 1;
optional AuthOpts auth = 2;
optional EncOpts enc = 2;
optional EncOpts enc = 3;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, this was awkward! Go and the spec were right, but I guess there is no one using topic descriptors in JS so far
Spec: https://github.com/libp2p/specs/tree/master/pubsub#the-topic-descriptor
Go: https://github.com/libp2p/go-libp2p-pubsub/blob/master/pb/rpc.proto#L61

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Types catching all the bugs 🎉

@@ -9,6 +9,7 @@ const log = Object.assign(debug('libp2p-pubsub:peer-streams'), {
/** @type Events */
const EventEmitter = require('events')

// @ts-ignore TODO: https://github.com/alanshaw/it-length-prefixed/pull/15
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been merged, can be removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am waiting on releasing this: alanshaw/it-length-prefixed#16
Otherwise tests fail

package.json Outdated Show resolved Hide resolved
vasco-santos and others added 2 commits April 12, 2021 10:12
Co-authored-by: Alex Potsides <alex@achingbrain.net>
@vasco-santos vasco-santos merged commit 8a6d3d0 into master Apr 12, 2021
@vasco-santos vasco-santos deleted the chore/update-pubsub-interface branch April 12, 2021 10:11
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants